The present invention relates to a method for programming a safety-oriented programmable logic controller, a router function block, an arithmetic logic unit, a computer program, and a computer program product.
Safety-oriented programmable logic controllers (SO-PLCs) are often programmed using the programming languages defined in IEC 61131-3 (e.g., ST: structured text; FBD: function block diagram; LD: ladder diagram; . . . ). Per the safety software requirements of ISO 13849-1 and EN 62061, the use of graphic programming languages such as LD and FBD is recommended. The present invention is not limited to these languages, but rather is directed in general to safety-oriented PLC programming. The programming is carried out using function blocks (program blocks), each of which contains one or more statements that are related in terms of technology or function. A complete PLC program is typically composed of a plurality of function blocks, it being possible to enter the individual blocks in different languages depending on the PLC application. Function blocks (FBs) contain the actual user program and may be supplied with different data at each invocation (“instances”). A safety-oriented function block is often referred to as a “SO-FB”, and a safety-oriented function block for activating a safe operating mode, e.g., motion, in a drive, is often referred to as a “safe motion FB”. Function blocks for programming a SO-PLC are closed program elements which must be tested and/or certified, e.g., by TUV or a professional association, depending on the applicable legal requirements.
The scope of safety-oriented functions in drives is continually increasing and offers far more than merely a safe shut-off of the machine. The applications are becoming increasingly more complex, in particular in the case of interconnected safety regions and/or multiple accesses to the danger zone. The safety functions must be differentiated between installers, operators, service personnel, and cleaning personnel. Due to the modular design of machines and the configuration requests of customers, there is a need for a flexible safety solution that is comparable to the classical automation solution.
Programmable safety systems are therefore replacing the classical, discretely wired concepts realized in relay logic to an increasing extent since they provide the flexibility that is required. The interface between the PLC and the drive is therefore particularly significant. Control and status information must be exchanged between the safety-oriented components. In addition, the status of the integrated safety functions must be synchronized with the status of the process control.
The interface between the safety-oriented logic (SO-PLC program) and the drive-integrated safety function (typically a safety monitor in the drive) includes inputs and outputs to the SO-PLC program, and “internal” signals to the system level, which must be routed by the programmer to the SO function in the drive. If a plurality of function blocks that activate a drive-integrated safety function is included in the PLC program, they must be interlocked by the programmer and transferred to the related signals (via hardware or field bus) in the drive since they typically have different priorities. These priorities must also be represented in the control in order to minimize the number of error messages generated due to priorities being violated.
One possible communication medium between the safety-oriented logic and the drive-integrated safety function (typically a safety monitor in the drive) is, e.g., a safe field bus transfer (e.g., PROFIsafe, SERCOS safety, etc.) or a hardware coupling. In this case as well, the programmer must utilize the appropriate interface on the side of the safety logic, i.e., depending on the medium used, the appropriate SO signals must be interconnected with the interface-dependent signals. These may differ depending on the communication medium. This is a complex undertaking and requires detailed knowledge of the various interfaces of the different communication media.
Finally, the SO-FBs must be instantiated individually by the SO programmer. In so doing, care must be taken to ensure that every FB is instantiated only once at the most. Otherwise, various instances of a SO-FB could request contradictory safety functions.
In all, implementing drive-integrated safety functions via the programming of a SO-PLC is a very elaborate task.
On the basis of this prior art, the present invention provides a method for programming a safety-oriented programmable controller, a router function block, an arithmetic logic unit, a computer program, and a computer program product having the features of the independent claims. Advantageous developments are the subject matter of the dependent claims and the description that follows.
The teaching according to the present invention relates to the programming of a safety-oriented programmable logic controller that is connectable to a device. The device provides an integrated safety function that is activatable using predetermined, in particular manufacturer-specific, first data. The programmable logic controller is now equipped with at least one first program part for providing second data for activating the device-integrated safety function, and with a second program part for automatically converting the second data into the first data.
The first and/or second program part are/is preferably a function block (FB) of a PLC programming environment; according to one aspect of the present invention, the second program part is a router function block. Although mainly function blocks are described below, it should be noted that the teaching according to the present invention relates to all types of first and second program parts, and is not limited to function blocks.
The device-integrated safety function is preferably a drive-integrated safety function. The safety functions of the drive are often realized as monitoring functions. When the monitoring functions in the drive become activated, they initiate a drive-based failsafe reaction. This case should not occur during operation, however, since it typically limits the availability of the system when synchronized axles are involved. As a result, a related control (motion control) should always specify appropriate guide variables so that the monitoring functions do not become activated.